Security risks, such as allowing unauthorized access to a user's system, are inherent with many on-line activities. Therefore, security mechanisms have been developed to protect users' systems. For example, a user may download an on-demand application from the Internet and execute the application from within the browser. To prevent unauthorized access to the user's system resources (e.g., a directory on the user's hard disk), the user's system is protected by “sandbox” security that is enforced within the browser environment. Sandbox security involves a limited, secure area of computer memory in which an application may execute, so that the application is prevented from accessing system resources that reside outside of the secure area.
In some circumstances, however, a user may wish to allow a downloaded application controlled access to certain resources within the user's system. For example, a user may wish to use an on-demand word processing application to generate a document and then save the document to a directory in the user's system.
Existing approaches for providing such applications with secure, controlled access to a user's system are too cumbersome and inflexible. In one method, for example, a security policy is defined within a policy database in which a given application is associated with a permission set. The security policy, in combination with origin information, signature information, and access restrictions, helps define a “trusted” relationship between the application and the user's system.
Consider the following example:
grant codeBase “http://www.BobsWidgets.com” signed by BobsCertificate{permission lang.io.FilePermission “/tmp/” “read”;permission lang.io.FilePermission “/tmp/bwdir/*” “write”;}
In the example, an applet from the source location, “www.BobsWidgets.com”, is granted certain file access permissions if it is signed with a key corresponding to another key contained in BobsCertificate. An applet traditionally is a program designed to be executed from within a browser, rather than directly from within the operating system. The applet is granted permission to read files from the “/tmp” directory on the host system and to create and write to files in the “/tmp/bwdir” directory. Permission to “execute” is another common permission modifier. Other security policy specifications may, for example, grant broad permissions to access files in any system location, regardless of the application's source or whether the application is unsigned or signed.
In such approaches, security policies are particularly static, remaining fixed over long periods of time. As on-demand application processing via the Internet becomes more prevalent, substantially static security policies are too limiting. Furthermore, the infrequent security policy changes that do occur (usually performed by a system administrator) can introduce security weaknesses or gaps, or prevent authorized applications from running by denying access to an application that had previously been granted access. As such, existing security architectures fail to dynamically and flexibly determine whether an application (or a given code assembly of an application) may be trusted with some amount of access to the user's system.
Furthermore, in existing security frameworks, allocation of permissions is determined by the security policy defined in the user's system, and possibly by a query to the user during execution or loading of the application. As such, a component of an on-demand application does not generally influence which permissions are allocated in accordance with a security policy. For example, a component from an authorized location may be granted extensive access to protected areas of a computer system, even though that component may not require or even desire such access. For liability reasons, the component may desire more limited access. In addition, a component may not be able to execute without a minimum set of permissions. In existing security frameworks, an inadequate permission grant set is detected only when a requested operation fails for lack of permission during execution of the code assembly, at which point execution time has been wasted and error recovery may be more complex.